I've written this up as a PR:
https://github.com/jsha/caa-simplification/pull/1/files. If there are no
objections, I'll merge it in a week for the 6844bis draft.

Note that I tweaked it slightly from your erratum
(https://www.rfc-editor.org/errata/eid5244). Where you referred just to
"issue" property tags, I mention both "issue" and "issuewild."

On 01/12/2018 01:41 PM, Corey Bonnell wrote:
>
> Hello,
>
> I believe that there are several ambiguities in RFC 6844 in regard to
> processing CAA resource record sets that do not contain "issue" records.
>
>  
>
> Section 3 of RFC 6844 (http://www.rfcreader.com/#rfc6844_line196)
> defines the "issue" property tag to authorize "the holder of the
> domain name <Issuer Domain Name> or a party acting under the explicit
> authority of the holder of that domain name to issue certificates for
> the domain in which the property is published". Based on my
> interpretation, the definition given here is suggesting that CAA issue
> restriction processing is done regardless of whether or not there is
> an "issue" record(s) present to specify the set of permitted Issuer
> Domain Names. In other words, the lack of "issue" records in a CAA
> resource record set indicates that no CA may issue for that domain,
> since no CA has been authorized to issue.
>
>  
>
> However, section 5.2 (http://www.rfcreader.com/#rfc6844_line447)
> defines the "issue" property tag to "request that certificate issuers
> perform CAA issue restriction processing for the domain and to grant
> authorization to specific certificate issuers". Based on this
> definition, it sounds as if CAA issue restriction processing is
> "opt-in". In other words, the absence of "issue" records in a CAA
> record set indicate that any CA may issue for that domain (since there
> was no "opt-in" into CAA restriction processing).
>
>  
>
> Section 4 (http://www.rfcreader.com/#rfc6844_line288) states that,
> "before issuing a certificate, a compliant CA MUST check for
> publication of a relevant CAA Resource Record set." Unfortunately, the
> term "relevant" is not defined by the RFC, which, compounded with the
> ambiguity highlighted above in regard to the definition of the "issue"
> property tag in sections 3 and 5.2, leads to ambiguity in the handling
> following scenarios:
>
>  
>
> - A CAA resource record set consisting solely of unknown non-critical
> property tags (including misspellings of "issue", such as "iisue", etc.)
>
> - A CAA resource record set consisting solely of "iodef" property tags
>
> - A CAA resource record set that contains both of the above
>
>  
>
> For each of these cases above, it is unclear which of the following
> three actions a CA should take:
>
> - Fail issuance (since the CAA resource record set did not authorize
> any CA to issue, given the definition of the "issue" property tag in
> Section 3)
>
> - Continue the tree-climbing search for records (since the resource
> record sets above could conceivably be considered as "not relevant")
>
> - Allow issuance (since the resource record sets above could
> conceivably be considered as "relevant" and any CA may issue, given
> the definition of the "issue" property tag in section 5.2)
>
>  
>
> At Trustwave, we have taken the conservative approach and will not
> issue certificates if we encounter CAA resource record sets matching
> the descriptions of the three above. However, given that we may be
> overly restrictive by doing this, as well as for a desire for CAA
> record sets to be processed uniformly regardless of the CA, we would
> like to see these ambiguities resolved.
>
>  
>
> If others agree that the current wording of the RFC is ambiguous, I
> would be happy to present changes to relevant sections to clear up the
> ambiguity, but for now I wanted to send this along to see if others
> share our interpretation of the RFC.
>
>  
>
> Thanks,
>
> Corey
>
>  
>
>  
>
>  
>
> *Corey Bonnell*
>
> Senior Software Engineer
>
> t: +1 412.395.2233
>
>  
>
> *Trustwave** *| SMART SECURITY ON DEMAND
> www.trustwave.com <http://www.trustwave.com/>
>
>  
>
> /2017 Best Managed Security Service Winner – SC Media/
>
>
>
> _______________________________________________
> Spasm mailing list
> Spasm@ietf.org
> https://www.ietf.org/mailman/listinfo/spasm